The invention concerns network communication, for example between a server terminal and an application terminal. It relates more particularly to a method and device making it possible to establish a communication channel on a network while the terminals do not have the same software interface for exchanging messages on the network. Such a situation arises, for example, when the server terminal is embodied by a smart card or the like.
In the following description, consideration will be given to the case of communication with a smart card comprising a service application (Applet) written in a high-level language, in particular an object-oriented language, such as Java, C++, etc. The assembly constituted by the card and the service application forms a card application. This assembly constitutes a server terminal capable of participating in communication with a client terminal, either local or on a network.
FIG. 1 depicts schematically the functional elements which are involved during communication in local mode between a smart card 2 and a client machine 4, the latter possibly being a terminal in a centralised system. A local connection LL provides the bidirectional exchange between the client machine 4 and the card 2 via respective communication interfaces 6 and 8. The local connection LL can be a serial or parallel cable between the client machine 4 and the card 2 (or its reader), or else a radio link if the card 2 operates in contactless mode.
The client machine 4 comprises the client application 10 which must establish a dialogue with a service application 12 integrated in the card 2 and hereinafter designated “card application”. In the example, the card application is implemented in a form referred to as an “Applet”, which is a recognised term within the context of the “JavaCard” language. At the level of the client and service applications, the dialogue is performed by messages in the high-level language sent by the client application 10 of the machine 4. These messages generally comprise processing instructions to be performed on data which are stored within the card 2. There will then be, for example, for a card electronic purse: m=purse debit (parameter=sum(numerical value), n=purse credit (parameter=sum(numerical value); O=balance (no parameter) (results of the operations). By way of illustration, the commands have a syntactic structure of the “debit(sum)” type (for the case of the aforementioned command m).
These commands cannot pass as such on the local connection LL, given that said connection imposes the use of specific protocol and formatting. There is then installed, on the client machine side of the local connection LL, a succession of software layers between the client application and the communication interface 6.
Starting from the client application 10, a first software layer constitutes what is referred to as the card application representative 14, also known by the term “proxy”. The representative is a layer developed and coded by the developer of the card application 12, which is used to present a software interface enabling communication with this application. It is an interface from the functional point of view of the card application, that is to say on the “job” side of the application, dedicated entirely to said application. The representative 14 then serves to establish compatibility of the commands of the client application 10 with those recognised by the card application 12. It is therefore necessary to produce the code of the representative according to the card application.
The framing of an element in the figures with a double line, used in particular for identifying the representative 14, indicates the codes to be developed and transmitted to the client machine 4 in order to be able to use the card application 12.
Thus, using again the example of a command of the client application 10 with the syntactic structure “do Sthg” with parameters, that is “do Sthg(parameters)”, the representative will produce—on the assumption that this command is recognised by the card application 12—a so-called formatting command, that is “format(do Sthg(parameters))”. It should be noted that the parameters can, if need be, be non-existent, giving the structure “do Sthg()”. In the following description, the parameters are not designated explicitly. Thus, using again the example of the aforementioned command m, its representation in the general form will be “do Sthg (parameters)”.
This formatting command is transmitted to a downstream so-called card formatting layer CFcard 16, which provides the conversion of the code issuing from this command into a message format adapted to the communication device. Its function is in particular to structure the message to be dispatched to the card application. By way of example, if the command is intended directly for the card 2, the format produced by the formatting layer 16 will be of the APDU (Application Protocol Data Unit) type; if it goes by means of a wireless protocol, it will conform to an SMS (Short Message Service) code; it can also be a format specific to a card, such as the JC21RMI (JavaCard 2.1 RMI) format.
Once the message has been structured, it is ready to be dispatched on the local connection LL. For this purpose, a communication protocol, that is a transport layer TRcard 18, which is responsible for sending the message, is used. This layer 18 provides the transport of the message according to a given protocol, for example: OTA (Over The Air), PCMCIA, Serial Port, etc. The transport layer TRCard 18 thus “packages” the messages which have been formatted in a structure adapted to transportation on the local connection LL. The messages thus packaged are then transmitted to the card 2, via the communication interfaces 6 and 8 and the local connection LL.
On the side of the card 2, there are found again the same layers as in the client machine 4 for successively carrying out the inverse operations (referred to as “dual” operations) in order to reach, from the data transmitted from the transport layer TRCard 18, the high-level command, in this case “do Sthg”.
Thus, at the card 2, the first layer on the side of the interface 8 is a dual transport layer TRcard−1 20 which has the function of “unpackaging” each message received on the local connection LL. In the case of the message coming from the command “do Sthg”, the dual layer TRcard−1 20 produces a command for “unformatting” the message “Card Msg”, that is “unformat(Card Msg)”.
This command is received by an unformatting layer CFcard−1 22, which is dual with regard to the layer CFcard 16, and which produces in response the order for transmitting the command “do Sthg(parameters)” to a card command driver 24.
The driver 24 essentially acts as a router, its function being to direct the command thus unformatted to the card application 12 which is intended for it.
The “Applet specific code” arrow F1 in the figure, between the card application 12 and the representative 14, indicates that, for the development of a card application (for example an Applet), the representative of this application must be installed on the client application.
Of course, the same instances of message processing are applied, in reverse order, for the returns of the card application 12 to the client application 10, as shown by the dotted arrows.
It may be noted that, in the figure, everything which exists between the various rectangles are calls to a routine in the rectangle situated downstream.
The “Card Message” entity (Card Msg) is an exchange format which contains the name of the method (for example “do Sthg”) and which structures the parameters according to the protocol which is going to be used next. The card message constitutes the complete method call, therefore its name and parameters, which will be structured according to a communication protocol.
When this message is dispatched to the transport layer TRcard 18, a change is made from the APDU protocol to the so-called TPDU protocol, which constitutes the transport protocol. For dispatching the message, it is broken down into a series of bits and packets on the line. The message is then effectively a coding of a function. When it passes over a transport layer, it is in the form of frames.
It may be understood that the representative constitutes a gateway which enables the client application 10 to dialogue as if the card application 12 were present on the client machine; in other words, it “represents” the service application in the sense that the client application interacts with the representative via the same high-level messages. The representative therefore has the same functional interface, at the same access level, as the service application in the card. In that way, when the client application is called to communicate with the service application in the card, this client application will not have to encode the messages in order to pass them to a driver module, but will instead only have to send the desired command.
The layers are always the same, irrespective of the devices. Thus, for communication between a client and a remote terminal, the stratification of the layers remains unvarying.
This community of layers is illustrated in FIG. 2, which represents a structure similar to that of FIG. 1, but applied to the case of communication on a network R, such as the Internet, between a client machine 30 and a server machine 32.
More particularly, communication is established between a client application 10, installed in the client machine 30, and a network server 34, analogous to the card application 12 of FIG. 1, installed in the server machine 32.
The network server 34 is then represented, at the client machine 30, by a network server representative 36, like the card representative 14 of FIG. 1.
In FIG. 2, and those which follow, the hardware communication interfaces are not depicted for reasons of simplicity, given that these means are well known.
The commands issuing from the network server representative 36 are processed successively by a network formatting layer CFnet 38 and a network transport layer TRnet 40, analogous respectively to the layers CFcard 16 and TRcard 18 of FIG. 1. The layer TRnet 40 provides in particular the division of the messages into frames adapted to the standards of transport on the network R.
On the side of the server machine 32, there are found again the dual transport layer TRnet−1 42 which takes delivery of the frames received from the network R and reconstructs them into messages as they were at the output of the layer CFnet 38.
The layer TRnet−1 42 is followed by the dual layer CFnet−1 44, which is a network unformatting code having the function of converting the reconstructed messages into high-level language, for example in the form “dispatch “do Sthg””.
The commands issuing from the layer CFnet−1 are transmitted to a network command driver 46, which delivers them to the application intended to process them, in this case the network server 34.
It may be noted that it is still necessary to develop the specific code for the network server representative 36 according to the server 34 it has to represent.
The use of the network server representative 36 and the network command driver 14 at the respective ends of the network R enables the client application 10 of the client machine 30 to isolate itself from the communication protocols, its operation as regards communication remaining at general format level. The representative and the command driver are generic with respect to the communication protocol.
From the message transmission structures according to FIGS. 1 and 2, it is conceivable, by simple concatenation of means, to make a card application communicate with a client application via a network R, and thus to make the card communicate with any remote terminal.
In this case, the card application will be connected to a network server via a local connection, and the client application will be connected to the network server via a network connection.
The implementation then consists of a concatenation of the transmission chains of FIGS. 1 and 2, as shown in FIG. 3. The elements of this figure already mentioned within the context of FIG. 1 or 2 bear the same references and will not be described again for the sake of conciseness.
According to this concatenation, there are found again on the side of the client machine 30 the client application 10 followed by its three layers: the “Network Applet” representative (call to the method) 36, the network formatting code (coding of the call) CFnet 38 and the network transport layer TRnet 40. In this specific case, the server representative 36 of FIG. 2 here becomes the representative of the card application (Applet), designated by the reference 36′.
At the terminal 31 associated with the card 2, downstream of the network R from the packet transmission layer TRnet, all the dual layers, namely successively TRnet−1 42 and CFnet−1 44, are gone back up through in order to transmit a command (“do Sthg”) to the command driver 46, in order that it is directed to the network server 34.
Next, the command “do Sthg” is re-dispatched from the network server 34 to the card application representative 14 within the terminal 31. The representative sends in response the command “format(“do Sthg”) to the layer CFcard 16 which then sends the card message (Card Msg) to the transport layer TRcard 18 so that this message is transmitted in packet form on the local connection LL to the card 2.
At the card 2, the packets are processed successively by the dual layers TRcard−1 20 and CFcard−1 22 in order to obtain the instruction for transmitting the command (“do Sthg”) to the card command driver 24. Finally, the latter transmits the command “do Sthg” to the card application 12.
To summarise, the production of a service application and a client application comprises the following steps:                writing of a service application;        writing of a representative for the terminals;        implementation of the client application with for example user interfaces (windows, menus, etc.), communicating in a high-level language with the card application representative.        
It may be noted that the main links in the communication chain between the client application on the client machine 30 and the card 2 application on the terminal 31 comprise: a network server 34, a network server representative 36′ and a representative 14 of the card application 12 at the terminal 31. Each of these elements 34, 36′ and 14 comprises computer code which is onerous to write and maintain. If the application changes so that it can make use of other messages, it then becomes necessary to take action separately on the code of each of these three links, the network representative 36′ having to be thus modified for all machines capable of communicating with the client application.
Part of this code can be produced by representative generation techniques, but it still remains that the installation or modification of an application in a network environment is tedious.
This code must furthermore be deployed, that is to say it is necessary to install the card representative 14 and the network server 34 on the respective terminals, connect these two links 14 and 34, and then install the representative on the client application. Next, all these three links must be connected in order to provide proper communication, in particular between the network server 34 and the card representative 14.
The deployment difficulties are then of the nature of management and maintenance. The more complex and long the code of these links is to produce, the greater are the risks of error, especially if said code is written manually.
Furthermore, on account of the large number of software layers between the client application 10 and the service application 12, the communication can suffer from a significant delay in response time. Moreover, the connections between each software layer involve interfacing problems which add to the aforementioned delays.
The effect of this is a significant delay in response time, since processing is performed at each link.
Finally, this approach lends itself badly to providing security from one end of the chain to the other. This is because it is then necessary to provide a step of encryption and decryption of the messages respectively upstream and downstream of each link 36′, 34 and 14 so that the messages can be understood by said links.
A proposal was recently made in “Mobile Objects Embedded in an Internet Smart Card, for the Commerce of Multimedia Virtual Objects”, P. Urien, Bull R&D, OCM 2000 Conference, Objects, Components and Models, “Past, Present and Future”, 18 May 2000, École des Mines de Nantes, for solving these problems of network access to a remote card by putting the card in the format of the network. The idea is then that, instead of having a particular protocol for communicating with the card, which necessitates the installation of a driver between the terminal and the card, the card is directly accessible as if it were a server on the network.
With this approach, the connection is established with a remote client, a standard network representative, the network, and the card directly connected to the network. There are no longer intermediate links between the card and the network.
However, it turns out that it is impossible to produce such a card in the current state of the art.